• 200828 Feb

    As this is my first post, I’d like to introduce myself. My names James and I’m currently working as a senior User Interface Developer for Teachers TV. Like many of you guys, I’m fanatical about web standards and about creating the leanest, most semantic markup possible. I too am excited about the new possibilities with the arrival of CSS3, and am keen to contribute as much as I can to this great site. My first post is regarding a new method of creating Tooltips that I devised while coming up with a solution for a recent project.

    Up until now, there were a few options in existence; ugly Javascript-based methods, or solutions that use blank anchor tags (for IE6 compatibility). Another possibility is to ignore IE6 altogether and make use of the hover pseudo class in conjunction with the parent element that contains the tooltip text. I had to think out the box a bit on this one, but have come up with a completely new CSS3-based solution.

    My solution degrades gracefully in browsers that don’t support the CSS3 elements I’ve used and is a lot more elegant than former methods since it utilises an element’s title attribute, rather than creating additional markup within a parent element.

    Let’s start with the HTML (Note: the following example is based on use of icon background images for the divs, hence the fixed dimensions):-

    <div title="Tooltip text for first div"></div>
    
    <div title="Tooltip text for second div"></div>

    In short, my method is achieved by making use of the :before (or :after) pseudo element and content property, combined with the :hover pseudo class.

    First off I grab the value of the divs title attribute by using the content property’s attribute function. Notice how I set the generated content to display:none -I’ll make it visible on :hover.

    div:before{
    	content:attr(title);
    	display:none;
    }

    I now combine both the :hover class and :before pseudo element together, to specify values for the generated content when the div is hovered over.

    div:hover::before{
    	width:200px;
    	display:block;
    	background:yellow;
    	border:1px solid black;
    	padding:8px;
    	margin:25px 0 0 10px;
    }

    One of the problems I came across at this stage, was that when having two elements floated left to each other and you hover over one of the elements, although the tooltip displays, it renders underneath the adjacent element. It is a simple case of layering the generated content over the div; my immediate thought was to specify a layering value in the above statement. However, after referring to the relevant W3C spec, it was apparent that in line with their recommendations, user agents ignore the position property in an instance such as the above statement, therefore rendering a z-index value useless.

    The solution was to specify the z-index and position properties in a separate statement dealing exclusively with the :hover pseudo class.

    div:hover{
    	z-index:10;
    	position:relative;
    }

    This meant that it now works! It of course works in every browser above IE7 including Safari 3, Firefox 2.0.0.12 & Opera 9.5b

    Obviously there’s nothing you can do to stop the default behaviour of standards compliant browsers regarding rendering of title attributes, so when leaving your cursor on my method for too long, the default browser behaviour will overlay the generated content CSS effect

    Live example of the final product

  • 200813 Feb

    One of the selectors new to CSS3 is the :target pseudo-class, which can be used to apply rules to an element with a fragment identifier; that is, an anchor name or an id. For example, let’s assume you have a section heading with an id of ‘chapter_2’:

    <h3 id="chapter_2">The Title of the Chapter</h3>

    You could create a direct link to that element by using the fragment identifier at the end of the URL:

    http://www.example.com/index.html#chapter_2

    And, with the :target selector, apply a background to that element to indicate clearly where you have arrived:

    h3:target { background-color: #ff0; }

    Pretty useful, right? Not a killer feature, but useful nonetheless. It can be made even more useful, however, with a little bit of ingenuity; how about, for example, a pure CSS image gallery?

    Take a look at this example (in a browser which supports :target; Mozilla, Webkit or Opera browsers will do the trick). Clicking the links allows you to browse through the different images, and it’s done with minimal markup and no scripting.

    The first step is to create a list, with the image, name, and link in each list item; for example:

    <li id="one">
    	<p><a href="#one">One</a></p>
    	<img src="https://www.css3.info/wp-content/uploads/2009/09/one.jpg">
    </li>

    Each list item needs an id, which will provide the anchor, and the link href is to its own id; this allows :target to work its magic! All the images are absolutely positioned on top of each other, and using the selector simply changes the z-index value so the targeted image is on top:

    img { position: absolute; }
    
    li:target img { z-index: 100; }

    Easy! Of course, this is only a very simple example; with even more ingenuity, this could be expanded to become a very useful tool.

    Update: I’ve just seen that Daniel Glazman came up with a very similar proposition before I did: CSS-only tabs.

  • 200713 Dec

    For those of you that haven’t seen, Dev Opera has just published a two part article series on styling form controls, by Christopher Schmitt. The first part covers using attribute selectors (which work in IE7, Opera, Safari and Firefox) to slim down your markup by providing a way to identify certain form controls without the addition of a class value. An example of this is using input[type="text"] in the CSS, rather than adding class="text" to the HTML file. The second part takes this further, by taking advantage of the :enabled, :disabled and :checked pseudo-classes, and a dash of opacity. The browser support for these pseudo-classes are not as strong however. According to Christopher, Opera is the only browser that supports all three correctly.

    If you are not aware of Dev Opera (known lovingly as Devo internally at Opera), it is Opera’s new developer site. Look out for a fantastic article on CSS3 from CSS3.info’s very own Peter Gasston in the near future.

  • 200718 Sep

    Until the Advanced Layout and Grid Layout modules are implemented, we have to get by with the existing tricks of the trade. One of those is the use of faux columns, a background image which simulates equal-height columns. This is a good technique, but the drawback is that it only works with fixed-width columns.

    That problem was overcome with the advent of liquid faux columns, which uses some background-position trickery and a bit of maths to create a variable-width effect.

    With the (tentative) introduction of background-size in Safari and Opera, however, faux columns are about to become a lot easier; all you need to do is create a background image and assign a percentage value to background-size, allowing the image to expand or contract with its containing box.

    Take a look at this example (only tested in Safari 3 and Opera 9.5; may work in Konqueror 3.5.7 also). If you resize your browser window, the text and columns should maintain their proportions.

    The way this is done is with a simple PNG image; I’ve made it 1000px wide, with two coloured columns of 250px each, so that it’s easier to calculate column widths (25%,50%,25%).

    I’ve set this as the background-image on the html element, which has been assigned a width of 90%. Inside this there is a container div with a width of 100%, and my three columns with the widths set at the same ratio as the background image:

    <div id="container">
    	<div id="one">
    	</div>
    	<div id="two">
    	</div>
    	<div id="tre">
    	</div>
    </div>
    
    #container {
    position: relative;
    width: 100%;
    }
    #one {
    margin: 0 25%;
    }
    #two, #tre {
    position: absolute;
    top: 0;
    width: 25%;
    }
    #two { left: 0; }
    #tre { right: 0; }

    The html element has the background-size declaration applied to it, with a percentage value to make it liquid, using the browser-specific prefixes followed by the proposed declaration (for safety):

    html {
    background-image: url('opera_bg.png');
    -khtml-background-size: 100%;
    -o-background-size: 100%;
    -webkit-background-size: 90%;
    background-size: 100%;
    background-position: 50% 0;
    background-repeat: repeat-y;
    width: 90%;
    

    You’ll notice that the Webkit value is different from the others; during this test, it seems that Webkit obtains its width from the entire browser window, not from the containing element; therefore, we have to set this value to be equal to the width of the containing element. I haven’t tested this thoroughly yet, so I’m not sure if this is a persistent bug or if there’s something I’m doing wrong. Anyway, Opera 9.5 behaves as expected.

    After that I’ve added the background-position and background-repeat declarations; background-repeat to tile the image down the page, and background-position because Webkit seems to ignore the margin values and puts the image at top left of the browser window; this is only necessary if you’re centre-aligning your page.

    Apart from a little tidying up, that’s it; once the module becomes a recommendation and the browser-specific prefixes are dropped, it will require only a few lines of code for the simple effect. In the meantime, remember that this is for experimentation purposes only and shouldn’t be used in a live environment. This is just a sketch of the technique at the moment, and requires more testing.

  • 200730 Jul

    I recently posted a preview of the CSS3 colour module on my own blog, but avoided using any actual examples. This was because of the things that have been implemented, the true power isn’t really seen using a simple example. With opacity and the HSLA/RGBA colour models, any elements that have been coloured just look like they fade to a lighter tint if there is only a white background behind it. Support for SVG colour keywords has also existed for a long time, just without being accepted by the validator.

    To show the true flexibility of CSS3 colour, I had to build a more complex example with overlapping elements. I also added a number of other CSS3 properties to show case them while I was at it (Why not?). Due to using a lot of transparency, there are a number of issues with Minefield, where it crawls to a hault then eventually stops responding. This may only be a issue with the Mac build or my hardware, so your mileage may vary. There shouldn’t be any issues with using webKit, except for a number of bugs that I seem to have uncovered. Most of these were hi-lighted in my previous post.

    Without further ado, here is the example for you to try out (warning large background image). It is based on a loose mock-up of a Mac OS X Leopard style interface. I needed a background image, so took a wallpaper from Michael Palin’s great Sahara series. The photo is copyright Basil Pao and is of a mother and her child in Tabelot, Niger.

    Because the example was designed to showcase the various colour values, I’ve mixed between using opacity, HSL, HSLA, RGB, RGBA (both hex and percentage) and keywords. In a real production site I’d have avoided this and stuck with the same colour models where appropriate. I tend to use keywords myself as they are easier (for me) to remember. HSL (and by extension HSLA) would be very useful when greater control over the colour is needed, but at the current moment it isn’t supported enough to be used. The correct RGB value would have to be used anyway to act as a fallback colour.

    The example showcases the difference between HSLA/RGBA and opacity. If you hover over the File or Go menus, I’ve added a sub menu that has opacity applied too it. When hovering over a menu item that is displayed over the white title bar behind it, you’ll notice the text is more white than the text with the mud background behind. This is because opacity is set on the foreground and well as the background. for elements that have been styled using HSLA or RGBA on the background colour, such as the faux-window title bars, contents area and menu bar, retain fully opaque text. While the difference isn’t too great with this example, there can be cases where the difference is quite obvious. It also allows things like just the shadows to have transparency.

    I’ve included quite a lot of other CSS3 into the mix. There is liberal use of box-shadow to give the allusion of depth on the windows and title bar. Rounded corners have been added to windows. There is an issue with rounded corners, where if overflow is set (which adds scroll bars) then the corner with the scroll bar ignores the radius (or is displayed behind it). I moved the overflow to a div inside the faux-windows to avoid this problem. I’m not sure how browsers can be fixed to avoid this problem without the spec changing to accommodate things like scroll bars. resize was added to both faux-windows, but there is issues with each element inside the window being resizable independently in Safari, and not being able to resize it smaller (the later wasn’t an issue in earlier builds).

    One of the big compatibility issues with current browser support is the difference between overflow using multi column layout. In Safari it doesn’t respect the setting of having two columns, by adding extra columns to the right of the visible columns. This seems smart at first as it avoids the issue of having to scroll to the bottom of the first column and back up to the start of the next column, however it is generally harder to scroll horizontally than vertically. You can also imagine if a height was set and overflow wasn’t used then it could push any content to the right of the columns out of view, such as a right hand side bar. Minefield just uses the two specified columns and makes the content as long as needed. This has issues as you get the scrolling problem mentioned previously. This will be a usability annoyance. My only suggestion is that a column height can be set, and when all available space is taken up without scrolling, a column break is inserted and columns of the same width and height are repeated below until the content runs out. There would have to be some way to specify the vertical column gap though. This would solve the readability issue, a one block of columns could be read at one time, and it will stop and important right sided content (or left in rtl layouts) from being pushed off the screen.

    The next CSS3 used was background-size. This was set at 100% so that no matter how big or small the browser window is, all the background image is shown (overflow:hidden; had to be added as the very latest versions of WebKit add scroll bars, unlike previous versions). This currently only works in WebKit. While most of this works fine in WebKit (if you ignore the bugs), one thing that only works in Opera and KHTML is the menu separators. Instead of adding mark-up such as a br I used the nth-child selector to select the exact element where the separator should go, and added the appropriate margin, border and padding. Without there being an element to group related list items, I though this was the best way to go about it, plus it was another excuse to show off more CSS3. Finally I used a attribute selector to grey out the print menu option (or any option in the menu with a URL of #). This is a bit of a hack to demonstrate the technique, but you can see how it could be useful in the real world.

    The great power I see coming with CSS3 is that this example looks fairly complex and flashy, yet only uses one image (the background image), and the mark-up is very brief. I could have used even less mark-up and ID/Class attributes, but they were added for semantic meaning. The problem is more that the browser has to do much more processing to work out things like the transparencies so there can be performance issues, especially on older hardware. One can expect that performance will be tuned as support for the new properties are included in final releases.

  • 200720 Jul

    While preparing an example of using the colours specified in the CSS3 Colour module, I come across something after Minefield (the nightly builds of Firefox 3) updated itself. It now supports the resize property from the Basic user interface module.

    Unfortunately, Minefield loads, then freezes and eventually doesn’t respond when trying to use this. This is unsurprising of a nightly release, and was likely due to the other CSS3 properties I was using on the example. The strange thing however is that the examples on the css3.info resize preview page do not work at all.

    I decided to strip out a lot of the extra styles and content that I was using, and have an example where resize works both in WebKit and the latest Gecko builds. As this is part of another example that isn’t quite finished yet, there are a number of bugs, which may or may not be my fault. There are also a number of styles which probably don’t need to be there, but are part of a bigger example, that will be coming soon. I just wanted something quick that would show this in action. Feel free to suggest any improvements.

    You can check out the resize example here.

    So what are the issues? In the example I wanted to make a faux window, much like a desktop application window. The whole window should be resizable as one block. For this I placed the resize on the app-window div. The main contents of the window had to be scrollable when there is too much contents for the size of the window, but the rest of the contents shouldn’t scroll, such as the title bar (a h2 element). Therefore I put the scroll on the contents div.

    In Safari there is a problem where both the h2 title bar and the main contents resize independently of each other. There doesn’t seem to be a way to resize the whole containing div where the resize is set. In Firefox this works correctly (or at least how I expected it to work). In Safari the content also can’t be resized smaller that the initial value of the div. This wasn’t an issue in an earlier build I was using while developing the example.

    Minefield can be resized down to the minimum size and width requested, but it only resizes correctly horizontally. The div resizes vertically but the containing content div doesn’t resize at all. This may be a bug of mine as the contents seems to break out of the container slightly at the bottom. I haven’t had time to look into this.

    One strange thing about Minefield’s support for resize is that it adds a cross-hair icon that allows one to move the contents around the page. This works correctly, unlike the resize, but I can’t find anywhere in the spec which specifies this should be allowed when using resize and it isn’t expected behaviour, or at least I wasn’t expecting it, and I didn’t specify that the div should be moveable. It would be nice to be able to specify this with a different property however.

    Also, as I use a Mac, I expect the content to be only resizable from the resize widget on the bottom right hand corner (for better or worse). Minefield ignores this and has its own controls, which can’t be styled as far as I know. I also can’t remove the resize controls after clicking out of the resizable content. They stay until the page is reloaded. As resize has probably just been implemented, it is expected that their will be a number of bugs like this however, so things should improve as more people test out this and other CSS3 properties. Resize with HSLA/RGBA and overflow: scroll; is particularly buggy for instance.

    I’m working on the original example, that I’ll post here at a later date, along with an updated version of the overview of the CSS3 Color Module that I posted on my personal blog recently. I guess I’ll have to report the bugs I’ve found to the appropriate places, unless it turns out I have bugs in my code instead.

Page 1 of 2:

OUR SPONSORS

Advertise here?
TAG CLOUD